Blockchain-based dynamic payterm generator

ABSTRACT

Systems, methods, and apparatus are provided for a dynamic contract payment term (“payterm”) generator. A machine learning algorithm may generate a replacement payment term for a contract based on market-based parameters and blockchain metadata for the contract. The blockchain metadata may encode hierarchical interdependencies between contracts using blockchain encryption. The blockchain metadata may be applied to auto-generate machine learning inputs for related contracts having interdependent payment terms. The machine learning inputs may include contract parameters that have been extracted and encrypted as blockchain metadata, as well as market-based parameters extracted from enterprise sources.

FIELD OF TECHNOLOGY

Aspects of the disclosure relate to leveraging blockchain-based contractencryption for smart generation of contract payment terms.

BACKGROUND OF THE DISCLOSURE

Enterprise contracts may involve a complex hierarchical web ofobligations. Pieces may include supercontracts, subcontracts, andmultiple statements of work (SOWs), as well as revised or updatedversions of all of these documents. Each document may include paymentterms that themselves present a number of options and contingencies.Moreover, employees who initially negotiate the payment terms of adocument may move on, leaving no one aware of the interrelationshipsbetween the documents or the evolution of party obligations.

A complete awareness of all related contract terms is itself ofteninsurmountable. An understanding of the content of these terms and therelative advantages of each payment option along with an assessmentmarket factors is beyond the capabilities of current systems.

It would be desirable to provide a computer utility capable ofautonomously using distributed ledger infrastructure to identifyinterrelated payment terms. It would further be desirable to combine thedistributed ledger infrastructure with machine learning algorithms todetermine a lowest cost payment schedule for the enterprise.

SUMMARY OF THE DISCLOSURE

Systems, methods, and apparatus for a blockchain-based dynamic paytermgenerator are provided.

A distributed ledger may store encrypted contract data in blockchainformat.

A first script may extract contract parameters from a plurality ofblockchain contracts in the distributed ledger and encrypt each set ofparameters as a metadata block associated with the correspondingcontract.

A second script may determine a hierarchical relationship between afirst contract and one or more related contracts from the plurality ofblockchain contracts and encrypt the hierarchy data as a metadata blockassociated with the first contract. The determination may be based, atleast in part, on the extracted contract parameters.

A third script may determine a subset of the related contracts eachhaving a payment term dependent on a payment term in the first contractand encrypt the dependent payment term data as a metadata blockassociated with the first contract. The determination may be based, atleast in part, on the extracted contract parameters.

A fourth script may extract a set of market-based parameters from anenterprise portal.

Auto-generated inputs to a machine learning algorithm may include theextracted contract parameters for the first contract and for the relatedcontracts having dependent payment terms. The inputs may include themarket-based parameters. The machine learning algorithm may generate anew payment term for the first contract based at least in part on theinputs.

An auto-managed repository may be in communication with the machinelearning algorithm. The repository may store evaluation logs and may beapplied to train and tune the machine learning algorithm.

A user interface may display the hierarchical relationship between thefirst contract and the related contracts. The display may include avisual indicator marking the subset of the related contracts each havinga payment term dependent on a payment term in the first contract.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects and advantages of the disclosure will be apparent uponconsideration of the following detailed description, taken inconjunction with the accompanying drawings, in which like referencecharacters refer to like parts throughout, and in which:

FIG. 1 shows illustrative apparatus in accordance with principles of thedisclosure;

FIG. 2 shows illustrative apparatus in accordance with principles of thedisclosure;

FIG. 3 shows an illustrative high-level process flow in accordance withprinciples of the disclosure;

FIG. 4 shows an illustrative process flow in accordance with principlesof the disclosure; and

FIG. 5 shows an illustrative process flow in accordance with principlesof the disclosure.

DETAILED DESCRIPTION

Systems, methods and apparatus for a dynamic blockchain-based smartpayterm generator are provided.

Enterprise contracts may involve a complex hierarchical web ofobligations. Pieces may include supercontracts, subcontracts, andmultiple statements of work (SOWs), as well as revised or updatedversions of all of these documents.

Each of these related documents may include payment terms that involvemultiple options or contingencies. For example, each payment term(alternately known as “payterms”) may include one or more early paymentdates, with different discount amounts applied for each date.

Processes that require comprehensive awareness the interdependencieswithin this hierarchy of contracts present a number of technicalchallenges. A first problem involves capturing the relationships betweenthese disparate contract documents. The contracts may be generated atdifferent times, by different enterprise divisions without any awarenessof each other, and may not be obviously related. Some of the contractdocuments may be digitized, while others may be physical contracts.

A blockchain is a distributed ledger of records which containinformation. Records stored in a blockchain are organized in blocks.Each block may include multiple records. The blocks are linked to oneanother and secured using cryptography.

Blockchain storage may capture the hierarchy of interrelated contracts.For example, as set forth above, some contracts may have multiplesubcontracts. Individual subcontracts in this array may have aparticular SOW or payment clause associated with them. The reality ofthese relationships can be captured through blocks of contract metadata.Blockchain encryption may involve hashing the metadata for an individualcontract block and for all of the contracts in a related superset. Anychanges to contract metadata may cause the system to flag the relatedcontracts.

A second challenge involves the dependencies between the various paymentterms and their multiple payment schedule options. Because the contractsare interrelated, a payment on one contract may affect the paymentoptions for the other related contracts. Market factors such as interestrates may also affect the timing for a contract payment. Although manypayment terms include a discount for early payment, this may not alwaysbe the most cost-effective option.

AI-based processing may leverage the blockchain system to auto-generateinputs from the blockchain contracts. The inputs may be based on thecontract interdependencies encoded in the blockchain. AI-basedprocessing may also incorporate inputs capturing market factors. One ormore machine learning algorithms may process the inputs and output a newcontract payment term that incorporates awareness of the entire field.

For the sake of illustration, the invention will be described as beingperformed by a “system.” The system may include one or more features ofapparatus and methods that are described herein and/or any othersuitable device or approach.

The system may include blockchain-based contract storage. For a digitalcontract, the system may determine whether a blockchain entry for thecontract exists. If no blockchain entry for the contract exists, thesystem may generate an entry. For a physical contract, the system mayscan and digitize the contract using optical character recognition (OCR)capabilities. A blockchain entry may be created for the newly digitizedphysical contract.

Once the blockchain contract storage is established, the system mayextract contract parameters. The system may use Python™ scripts or anysuitable program in any suitable language to extract contractparameters. Python is a registered trademark of the Python SoftwareFoundation. Python is an interpreted, object-oriented, high-levelgeneral-purpose programming language.

A contract reader may scan the blockchain contracts to filter out therelevant contract parameters. An information extractor may incorporatethe scanned data into a set of contract parameters.

The system may extract any suitable contract parameters. The contractparameters may be predetermined by the system or by a system user. Insome embodiments, specific parameters may be selected on a case-by-casebasis via a user interface. Illustrative contract parameters may includea payment term for the contract, an amount of a payment, a discount termfor the contract, an amount of a discount, vendor information, a latestpayment date, a previous payment term for similar products or services,and a total spend on products or services.

The extracted contract parameters may be stored as a metadata block inassociation with the blockchain contract.

The information extractor may determine whether payment is required forthe entire contract or whether there is a schedule of partial payments.The information extractor may determine whether payments will be madefor subcontracts, SOWs or discrete sections of the contract. Thedetermination may be based on the extracted contract parameters.

For physical contracts, manual inputs may capture contract parameters.The contract parameters for manual input may be the same as the contractparameters extracted by the system. The contract parameters for manualinput may be different from the contract parameters extracted by thesystem. An input profiler may check the inputs for standardized dataformats. The input profiler may convert the inputs to a unified formatfor storage on the blockchain.

A contract analyzer may analyze the extracted contract parameters andidentify relationships between contracts. Relationships betweencontracts may be determined based on common clauses, common parties,common products, common payment dates or any other suitable informationshared between the two contracts. Relationships between contracts may bedetermined based on extracted contract parameters or manually inputcontract parameters.

The relationships may include a hierarchical arrangement involving acontract and one or more subcontracts or SOWs. The system may generatecontract metadata blocks associated with the contractinterrelationships. The contract analyzer may arrange the metadatablocks according to the contract hierarchy using the blockchain hashing.For a physical contract, the contract analyzer may generate the contractmetadata based on the standardized manual inputs.

A contract separator may separate contracts within the hierarchy thathave interdependent payment terms. The contract separator may be alignedwith the blockchain. The contract separator may trace the hierarchy toidentify any blocks that would be affected by a payment on a relatedcontract. For each contract, the system may generate a metadata blockthat includes information associated with any payment terminterdependencies.

The system may include a user interface. The user interface may beconfigured to display the hierarchical relationships between contracts.The display may include a vertical and/or horizontal arrangement thatincorporates graphical representations of the contracts andsubcontracts. The display may show the contracts and subcontracts ondifferent tiers of the hierarchy. The display may use lines, arrows orany suitable connectors to show relationships between the contracts. Thedisplay may mark contracts within the hierarchy that have interdependentpayment terms using a visual indicator. The display may usehighlighting, color-coding, typeface changes, borders, text, or anysuitable means to mark the contracts having interdependent paymentterms.

The system may include one or more machine learning algorithms. Thesystem may perform feature engineering on the metadata from theblockchain including the extracted contract parameters, the manuallyinput contract parameters, the hierarchy metadata generated by thecontract analyzer, and the metadata generated by the contract separator.Feature engineering may prepare the input data for machine learning bycreating features from the raw data. The system may use domain knowledgeof contracts to determine relevance and importance of dataset featuresthat the machine learning model will need to determine a target output.In some embodiments, new features may also be created from existingfeatures using feature crossing. The system may use hyper-parametertuning to pre-process the contract parameters. The system may useexploratory data analysis or any other data science protocols to preparethe blockchain-based inputs and the manual inputs for machine learning.

Additional inputs to the machine learning algorithm may capture marketfactors such as interest rates, currency valuation, or local compliancenorms. Python scripts or any suitable program in any suitableprogramming language may be used to extract market data from anenterprise source. The source may include internal data from anenterprise portal. An input profiler may standardize the extracted datato generate unified inputs. An input validator may perform data qualitychecks using any suitable data quality metric.

Additional inputs to the machine learning algorithm may include paymenthistory data. The system may determine whether payments were made forany related contract. Payment history for any of the contracts may bestored in an auto-managed repository.

The machine learning algorithm may analyze contract parameters for agiven contract and for contracts having interdependent payment terms.The relevant inputs may be identified via the blockchain metadata forthe given contract.

The machine learning algorithm may analyze the inputs and determine theoutcomes of various combinations of contract payment options. Themachine learning algorithm may determine the effect of making a paymenton the other related contracts. The system may include regression,classification, cluster analysis or any suitable machine learningalgorithms. In some embodiments, the machine learning model mayincorporate multiple machine learning algorithms. The multiplealgorithms may be applied selectively or may be applied in sequence.

The system may output an optimized payment term for a contract. The newpayment term may be based on an evaluation of all possible paymentoptions for all related contracts, as well as payment history data andmarket status data.

Before the inputs are submitted to the machine learning algorithm, thesystem may determine whether there is system history involving the samecontract parameters. Evaluation logs for the machine learning model maybe stored in an auto-managed repository. The system may access theauto-managed repository to determine whether the same scenario has beenpreviously evaluated. If a scenario has already been analyzed, thesystem may bypass the machine learning evaluation, increasing outputefficiency and reducing the data footprint.

The efficiency and accuracy of the machine learning model may improveover time. Inputs to the machine learning algorithm from the blockchainand from market trends, including the associated evaluation logs, may bemaintained in the auto-managed repository. Data in the auto-managedrepository may be applied to train the machine learning model. As setforth above, repository data may also be used to provide directevaluation for similar inputs, increasing efficiency and reducing thedata footprint for the system. Additionally, information regarding paidand unpaid contracts may be flagged and stored in the repository forfuture reference.

One or more non-transitory computer-readable media storingcomputer-executable instructions are provided. When executed by aprocessor on a computer system, the instructions perform a method forautonomous capture of hierarchical relationships between contracts viablockchain encryption and for smart generation of a payment term based,at least in part, on the blockchain structure.

The method may include extracting a set of contract parameters fromblockchain contracts in a distributed ledger and encrypting theextracted contract parameters as a metadata block associated with thecorresponding contract. Contract parameters for physical contracts maybe obtained via manual inputs.

The method may include determining a hierarchical relationship between afirst blockchain contract and one or more related blockchain contractsand encrypting the hierarchy data as a metadata block associated withthe first contract. The determination may be based at least in part onthe contract parameters for each of the related contracts.

The method may include determining a subset of the related contractseach having a payment term affected by a payment term in the firstcontract and encrypting the affected payment term data as a metadatablock associated with the first contract. The determination may be basedat least in part on the contract parameters for each of the relatedcontracts.

The method may include extracting market-based parameters from anenterprise portal.

The method may include, using a machine learning algorithm, generating anew payment term for the first contract. The auto-generated inputs forthe machine learning algorithm may include contract parameters for thefirst contract, contract parameters for the related contracts havingaffected payment terms, and market parameters.

The method may include displaying the hierarchical relationship betweenthe first contract and the related contracts and marking, with a visualindicator, the subset of the related contracts having payment termsaffected by a payment term in the first contract.

Systems, methods, and apparatus in accordance with this disclosure willnow be described in connection with the figures, which form a parthereof. The figures show illustrative features of apparatus and methodsteps in accordance with the principles of this disclosure. It is to beunderstood that other embodiments may be utilized, and that structural,functional and procedural modifications may be made without departingfrom the scope and spirit of the present disclosure.

The steps of methods may be performed in an order other than the ordershown and/or described herein. Method embodiments may omit steps shownand/or described in connection with illustrative methods. Methodembodiments may include steps that are neither shown nor described inconnection with illustrative methods. Illustrative method steps may becombined. For example, an illustrative method may include steps shown inconnection with any other illustrative method.

Apparatus may omit features shown and/or described in connection withillustrative apparatus. Apparatus embodiments may include features thatare neither shown nor described in connection with illustrativeapparatus. Features of illustrative apparatus may be combined. Forexample, an illustrative apparatus embodiment may include features shownor described in connection with another illustrative apparatus/methodembodiment.

FIG. 1 is a block diagram that illustrates a computing device 101(alternatively referred to herein as a “server or computer”) that may beused in accordance with the principles of the invention. The computerserver 101 may have a processor 103 for controlling overall operation ofthe server and its associated components, including RAM 105, ROM 107,input/output (′I/O″) module 109, and memory 115.

I/O module 109 may include a microphone, keypad, touchscreen and/orstylus through which a user of device 101 may provide input, and mayalso include one or more of a speaker for providing audio output and avideo display device for providing textual, audiovisual and/or graphicaloutput. Software may be stored within memory 115 and/or other storage(not shown) to provide instructions to processor 103 for enabling server101 to perform various functions. For example, memory 115 may storesoftware used by server 101, such as an operating system 117,application programs 119, and an associated database.

Alternatively, some or all of computer executable instructions of server101 may be embodied in hardware or firmware (not shown).

Server 101 may operate in a networked environment supporting connectionsto one or more remote computers, such as terminals 141 and 151.Terminals 141 and 151 may be personal computers or servers that includemany or all of the elements described above relative to server 101. Thenetwork connections depicted in FIG. 1 include a local area network(LAN) 125 and a wide area network (WAN) 129, but may also include othernetworks.

When used in a LAN networking environment, computer 101 is connected toLAN 125 through a network interface or adapter 113.

When used in a WAN networking environment, server 101 may include amodem 127 or other means for establishing communications over WAN 129,such as Internet 131.

It will be appreciated that the network connections shown areillustrative and other means of establishing a communications linkbetween the computers may be used. The existence of any of variouswell-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like ispresumed, and the system may be operated in a client-serverconfiguration to permit a user to retrieve web pages from a web-basedserver. Any of various conventional web browsers may be used to displayand manipulate data on web pages.

Additionally, application program 119, which may be used by server 101,may include computer executable instructions for invoking userfunctionality related to communication, such as email, short messageservice (SMS), authentication services and voice input and speechrecognition applications.

Computing device 101 and/or terminals 141 or 151 may also be mobileterminals including various other components, such as a battery,speaker, and antennas (not shown). Terminal 151 and/or terminal 141 maybe portable devices such as a laptop, tablet, smartphone or any othersuitable device for receiving, storing, transmitting and/or displayingrelevant information.

Any information described above in connection with database 111, and anyother suitable information, may be stored in memory 115. One or more ofapplications 119 may include one or more algorithms that encryptinformation, process received executable instructions, interact withenterprise systems, perform power management routines or other suitabletasks. Algorithms may be used to perform the functions of one or more ofextracting contract parameters, analyzing contract parameters, featureengineering, machine learning modeling, and/or perform any othersuitable tasks.

The invention may be operational with numerous other general purpose orspecial purpose computing system environments or configurations.Examples of well-known computing systems, environments, and/orconfigurations that may be suitable for use with the invention include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, tablets, mobile phones and/or other personal digitalassistants (“PDAs”), multiprocessor systems, microprocessor-basedsystems, set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

The invention may be described in the general context ofcomputer-executable instructions, such as program modules, beingexecuted by a computer. Generally, program modules include routines,programs, objects, components, data structures, etc. that performparticular tasks or implement particular abstract data types. Theinvention may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media including memory storage devices.

FIG. 2 shows an illustrative apparatus 200 that may be configured inaccordance with the principles of the invention.

Apparatus 200 may be a computing machine. Apparatus 200 may include oneor more features of the apparatus that is shown in FIG. 1 .

Apparatus 200 may include chip module 202, which may include one or moreintegrated circuits, and which may include logic configured to performany other suitable logical operations.

Apparatus 200 may include one or more of the following components: I/Ocircuitry 204, which may include a transmitter device and a receiverdevice and may interface with fiber optic cable, coaxial cable,telephone lines, wireless devices, PHY layer hardware, a keypad/displaycontrol device or any other suitable encoded media or devices;peripheral devices 206, which may include counter timers, real-timetimers, power-on reset generators or any other suitable peripheraldevices; logical processing device 208, which may extract contractparameters, generate contract metadata, encrypt contract data andmetadata, and perform other methods described herein; andmachine-readable memory 210.

Machine-readable memory 210 may be configured to store inmachine-readable data structures: contract data and metadata, extractedcontract parameters, market parameters, contract payment history,generated payment terms and any other suitable information or datastructures.

Components 202, 204, 206, 208 and 210 may be coupled together by asystem bus or other interconnections 212 and may be present on one ormore circuit boards such as 220. In some embodiments, the components maybe integrated into a single chip. The chip may be silicon-based.

FIG. 3 shows high-level system architecture 300. Contracts 302 may bedigitized contracts stored in blockchain format. Blockchain alignedcontract separator 304 may break out related contracts that will beaffected by a contract payment. Physical contract inputs 306 may also beanalyzed by the contract separator and used to identify relatedcontracts.

Digital contract reader and extractor 310 may provide extracted contractparameter inputs for a contract as well as extracted contract parameterinputs from related blockchain contracts. Related contracts withinterdependent payment terms may be identified based on metadatagenerated by the contract separator.

Market parameter inputs 308 may be extracted from enterprise sources.The market parameter inputs and the contract parameter inputs may beinput into machine learning algorithm 312. The machine learning model isshown in communication with a smart disk. The smart disk may storeevaluation logs and contract payment history. Data from the smart diskmay be used for model training and tuning.

FIG. 4 shows illustrative process flow 400. Aspects of process flow 400may be shown in architecture 300. At step 402 physical and digitalcontracts enter the system.

Steps 402 to 424 show the auto-generation of blockchain-based inputparameters. Steps 404-406 apply to physical contracts. At step 404, auser may enter manual inputs related to the parameters of a physicalcontract. At step 406, input profiling may ensure that the inputs arestandardized to correlate with the contract parameters extracted fromblockchain contracts. The physical contract may be digitized, and thecontract parameters may be encrypted as a metadata block associated withthe contract (not shown).

Steps 408-414 apply to digital contracts. At step 408, the systemdetermines if the digital contract exists in blockchain format. If thecontract does not exist as blockchain, at step 410, the contract isencrypted in blockchain format. The process continues with step 412. Atstep 412, a contract reader scans the blockchain contract. At step 414,the information extractor filters out the desired contract parameters.The contract parameters may be encrypted as a metadata block associatedwith the contract.

At step 416, the system analyzes the contract parameters obtained frommanual inputs or from the blockchain to determine whether payment isrequired for the entire contract or whether subcontracts, statements ofwork or partial payments are involved. If multiple payment options arepossible, the process continues at step 418, otherwise the processcontinues at step 422.

At step 418, the contract analyzer analyzes the contract parameters anddetermines hierarchical relationships between contracts. Thehierarchical relationships may be encrypted as a metadata blockassociated with a contract. At step 420, a contract separator breaks outthe related contracts having dependent payment terms. The existence ofthese dependent payment terms may be encrypted as a metadata blockassociated with a contract. The contract analyzer and contract separatormay be Python-based utilities.

At step 422, feature engineering may be performed on the contractparameters to generate features from the raw data for input into amachine learning algorithm. At step 424, the parameter format isstandardized. If the parameter format is not compatible with the machinelearning based processing, the process iterates back through step 422.

Steps 426 to 432 show the auto-generation of market-based parameters.Step 426 shows enterprise market analytics. The analytics may include afeed from an internal enterprise portal. At step 428, an input extractorextracts market parameters that may affect a contract payment from theenterprise feed. At step 430, an input profiler standardizes thecontract parameters. At step 432, an input validator performs qualitychecks on the data. The input validator may use any suitable dataquality metric.

Steps 434-440 show AI-based payment term generation. At step 434, theblockchain-based inputs and the market-based inputs are processed by themachine learning model to determine whether an identical set of data hasbeen previously analyzed. An auto-managed repository may storeevaluation logs showing past inputs and past outputs by the machinelearning algorithm. If an identical scenario has already been logged,the system may bypass the machine learning algorithm and output acontract payment term at step 440.

If no identical scenario has been logged, at step 436, the contractparameters and the market parameters may be input into the machinelearning algorithm. The machine learning algorithm may generate a newcontract payment term based on the related contracts and the marketparameters. At step 440, the system may output the new contract paymentterm. The new contract payment term may be optimized for lowest cost.

At step 438, the machine learning algorithm may be in communication withthe auto-managed repository. The auto-managed repository may storeevaluation logs showing operations of the machine learning algorithm.The auto-managed repository may provide feedback to the machine learningalgorithm.

FIG. 5 shows illustrative process flow 500. Aspects of process flow 500may also be shown in architecture 300 and process flow 400.

Hierarchy 502 shows relationships between contracts. Starting withsubcontract 14 (boxed in bold) it is apparent that contract 1,subcontracts 3, 7 and 8 (also boxed in bold) are all related. Each ofthese blockchain contracts may include metadata that identifies therelated subcontracts in the hierarchy. The metadata identifying relatedcontracts may be hashed using the unique blockchain signature for thecontract.

Contract analyzer 504 may read each of the contract branches. Contractseparator 506 may determine which contracts from each branch haveinterdependent payment terms. Contract analyzer 504 and contractseparator 506 may be Python-based utilities.

Hierarchy 508 shows relationships between contracts in the hierarchyhaving dependent payment terms. As determined in hierarchy 502,subcontract 14 is related to contract 1 and to subcontracts 3, 7 and 8.However, contract hierarchy 508 shows that only contract 1 andsubcontract 7 will be affected by a payment to subcontract 14. Thecontract separator breaks out these contracts and stores the dependentpayment term information as blockchain metadata.

The blockchain metadata may include extracted contract parameters foreach of the contracts in the hierarchy. The blockchain metadata forcontracts with interdependent payment terms may be processed as inputsfor the machine learning algorithm.

Hierarchies 502 and/or 508 may be displayed to a user via a userinterface. The display may use color-coding or any suitable visualindicator to mark the related contracts and the contracts havingdependent payment terms within the hierarchy.

Thus, methods and apparatus for a BLOCKCHAIN-BASED DYNAMIC PAYTERMGENERATOR are provided. Persons skilled in the art will appreciate thatthe present invention can be practiced by other than the describedembodiments, which are presented for purposes of illustration ratherthan of limitation, and that the present invention is limited only bythe claims that follow.

What is claimed is:
 1. A system for autonomous capture of hierarchicalrelationships between contracts via blockchain encryption and smartgeneration of a contract payment term based at least in part on theblockchain structure, the system comprising: a distributed ledgerconfigured to store encrypted data in blockchain format, the distributedledger storing one or more blockchain contracts; a processor configuredto: using a first script, determine a hierarchical relationship betweena first blockchain contract and one or more related blockchain contractsfrom the distributed ledger, and encrypt the hierarchy data as ametadata block associated with the first blockchain contract; using asecond script, determine a subset of the related contracts each having apayment term dependent on a payment term in the first contract, andencrypt the dependent payment term data as a metadata block associatedwith the first blockchain contract; and using a machine learningalgorithm, output an optimized payment term for the first contract,wherein inputs for the machine learning algorithm are autogenerated fromthe blockchain metadata; an auto-managed repository configured to storethe generated payment term and the machine learning algorithm inputs,the processor further configured to determine, before engaging themachine learning algorithm, whether an identical set of inputs and anassociated generated payment term are stored in the auto-managedrepository; and a user interface configured to display the hierarchicalrelationship between the first contract and the related contracts and tomark, with a visual indicator, the subset of the related contracts eachhaving a payment term dependent on a payment term in the first contract.2. The system of claim 1 wherein the processor is further configured to,using a third script: extract a set of contract parameters from each ofa plurality of blockchain contracts in the distributed ledger; andencrypt the extracted contract parameters for each contract as ametadata block associated with the contract; wherein the machinelearning algorithm inputs comprise the extracted contract parameters forthe first contract and for a subset of the related contracts each havinga payment term dependent on a payment term in the first contract.
 3. Thesystem of claim 2 wherein the extracted contract parameters comprise apayment date, a payment amount, a discount date and a discount amount.4. The system of claim 2 wherein determination of the hierarchicalrelationship is based at least in part on the extracted contractparameters for the first contract and for each of the related contracts.5. The system of claim 2 wherein the determination of the subset ofrelated contracts each having a payment term dependent on a payment termin the first contract is based at least in part on the extractedcontract parameters for the first contract and for each of the relatedcontracts.
 6. The system of claim 2 wherein: the processor is furtherconfigured to, using a fourth script, extract a set of market-basedparameters from an enterprise portal; and the machine learning algorithminputs further comprise the extracted market-based parameters.
 7. Thesystem of claim 2 wherein: the processor is further configured toreceive contract parameters for a physical contract via a manual input;and the machine learning inputs comprise the received contractparameters.
 8. The system of claim 6, wherein the third script forextracting contract parameters from the blockchain and the fourth scriptfor extracting market parameters from the enterprise portal are Pythonscripts.
 9. One or more non-transitory computer-readable media storingcomputer-executable instructions which, when executed by a processor ona computer system, perform a method for capturing hierarchicalrelationships between contracts via blockchain encryption and generatinga payment term based at least in part on the blockchain structure, themethod comprising: extracting a set of contract parameters from each ofa plurality of blockchain contracts in a distributed ledger andencrypting the extracted contract parameters for each contract as anassociated metadata block; determining a hierarchical relationshipbetween a first contract and one or more related contracts from theplurality of blockchain contracts, the determination based at least inpart on the extracted contract parameters for each contract, andencrypting the hierarchy data as a metadata block associated with thefirst contract; determining a subset of the related contracts eachhaving a payment term dependent on a payment term in the first contract,the determination based at least in part on the extracted contractparameters for each contract, and encrypting the dependent payment termdata as a metadata block associated with the first contract; using amachine learning algorithm, generating a new payment term for the firstcontract, wherein inputs for the machine learning algorithm comprise theextracted contract parameters for the first contract and for the relatedcontracts having dependent payment terms; storing the generated paymentterm and the machine learning algorithm inputs in an auto-managedrepository; and displaying the hierarchical relationship between thefirst contract and the related contracts and marking, with a visualindicator, the subset of the related contracts each having a paymentterm dependent on a payment term in the first contract.
 10. The media ofclaim 9, wherein the contract parameter inputs for the machine learningalgorithm comprise a payment date, a payment amount, a discount date,and a discount amount.
 11. The media of claim 9, further comprisingextracting a set of market-based parameters from an enterprise portal,wherein the machine learning algorithm inputs further comprise theextracted market-based parameters.
 12. The media of claim 9, furthercomprising storing data associated with a first contract payment in theauto-managed repository and flagging each related contract having adependent payment term with the first contract payment data.
 13. Themedia of claim 9, further comprising determining, before engaging themachine learning algorithm, whether an identical set of inputs and anassociated generated payment term are stored in the auto-managedrepository.
 14. The media of claim 9, further comprising receivingcontract parameters for one or more physical contracts via manual input.15. The media of claim 11, wherein scripts for extracting contractparameters from the blockchain and extracting market-based parametersfrom the enterprise portal are Python scripts.
 16. A method forcapturing hierarchical relationships between contracts via blockchainencryption and generating a payment term based at least in part on theblockchain structure, the method comprising: extracting a set ofcontract parameters from each of a plurality of blockchain contracts ina distributed ledger and encrypting the extracted contract parametersfor each contract as an associated metadata block; determining ahierarchical relationship between a first contract and one or morerelated contracts from the plurality of blockchain contracts, thedetermination based at least in part on the extracted contractparameters for each contract, and encrypting the hierarchy data as ametadata block associated with the first contract; determining a subsetof the related contracts each having a payment term dependent on apayment term in the first contract, the determination based at least inpart on the extracted contract parameters for each contract, andencrypting the dependent payment term data as a metadata blockassociated with the first contract; using a machine learning algorithm,generating a new payment term for the first contract, wherein inputs formachine learning algorithm comprise the extracted contract parametersfor the first contract and for the related contracts having dependentpayment terms; storing the generated payment term and the machinelearning algorithm inputs in an auto-managed repository; and displayingthe hierarchical relationship between the first contract and the relatedcontracts and marking, with a visual indicator, the subset of therelated contracts each having a payment term dependent on a payment termin the first contract.
 17. The method of claim 16, further comprisingreceiving contract parameters for one or more physical contracts viamanual inputs.
 18. The method of claim 17, wherein the contractparameter inputs into the machine learning algorithm comprise a paymentdate, a payment amount, a discount date, and a discount amount.
 19. Themethod of claim 16, further comprising extracting a set of market-basedparameters from an enterprise portal, wherein the machine learningalgorithm inputs further comprise the extracted market-based parameters.20. The method of claim 17, further comprising determining, beforeengaging the machine learning algorithm, whether an identical set ofinputs and an associated generated payment term are stored in theauto-managed repository.
 21. The method of claim 19, further comprisingperforming one or more preprocessing operations on the contractparameters and the market parameters prior to inputting the parametersinto the machine learning algorithm.